The offboard branch above (line ~735) runs the same NAV_RCL_ACT lookup but doesn't return — it falls through to the rest of the function. Worth aligning so all three sites behave the same.

Concretely, with the early return, NAV_RCL_ACT=0 (Disabled, accepted by gcs_connection_loss_failsafe_mode::Disabled) returns Action::None and skips the bottom-of-function modeCanRun catch. Without the return, the cascade would continue. Either choice is defensible — just make them consistent.

Third copy of the same pattern now (offboard + the two new blocks). Consider extracting:

Action rcLossOverride() const {
    return fromNavDllOrRclActParam(_param_nav_rcl_act.get()).action;
}

…or moving the RC check to a single post-cascade step. Easier to keep them in sync next time someone adds a fallback path.

With default NAV_RCL_ACT=2 (Return), this assertion would still hold if the new code hard-coded Action::RTL instead of reading the parameter. Adding a sibling test that sets NAV_RCL_ACT to e.g. Land or Hold and asserts the corresponding action would actually validate the parameter linkage.

Worth a comment that Descend here is the framework cascade RTL→Land→Descend kicking in (because local_altitude_invalid blocks AUTO_RTL/AUTO_LAND), not what checkModeFallback directly returns. Reads as surprising on a first pass otherwise.